1. Field of the Invention
The present invention relates to a Voice Call Continuity (VCC), and more particularly, to a method and system for controlling VCC functions initiated by a network in which the VCC functions are enabled or disabled by exchanging information regarding the VCC functions between a terminal and a network server. The present invention also relates to the terminal and network server for implementing the method.
2. Discussion of the Background Art
In general, a Voice Call Continuity (VCC) refers to a service for allowing a call path exchange of voice calls between a 3GPP Circuit Switching (CS) system (e.g., GSM, UMTS) and an IP Multimedia Subsystem (IMS). That is, the VCC refers to a type of application, namely, a home IMS application which is capable of transporting voice calls between the CS domain and IMS domain. As such, the VCC provides functions of voice call originations, voice call terminations, a domain selection and a domain transfer from the CS domain to the IMS domain or vice versa. Here, the domain transfer refers to transferring access legs for voice calls toward a User Equipment (UE) (i.e., a terminal) from the CS domain to the IMS domain or vice versa during an active session. The access leg denotes a call control leg between a VCC UE and a Domain Transfer Function (DTF) of a VCC application (server).
Through the domain transfer procedures of the VCC service, continuity for one or more voice sessions is provided between the IMS domain and CS domain while the VCC UE performs the one or more voice sessions. That is, the VCC services provides continuity to the voice call by switching from the IMS domain to the CS domain or vice versa, e.g., when the current domain for the call is not suitable or desired.
The domain transfer for a certain voice call/session from the CS domain to the IMS domain or vice versa is initiated only when a DTF is positioned (located) on a signal path of the voice call/session setup. For this, positioning of the DTF on the way of the signal path of the voice call/session setup is referred to as anchoring in IMS or anchoring.
FIG. 1 illustrates an architecture of a network for providing a VCC service.
As illustrated in FIG. 1, a VCC UE 10 denotes all types of terminals which can support the VCC service. The VCC UE can access the CS and PS (packet switched) domains. That is, when accessing the CS domain, the VCC UE uses a UE-CS (not shown) provided therein, whereas the VCC UE uses a UE-IMS (not shown) provided therein when accessing the PS domain.
A VCC application 30 is an application server for providing the VCC service, and is constituted with entities which perform a series of functions. The series of functions may include functions required to setup voice calls toward the VCC UE, and functions required to switch an access leg of the VCC UE between the CS domain and the IMS domain with maintaining (performing) an active session. Here, the series of functions can be, but are not limited to, a Domain Transfer Function 30a, a Domain Selection Function 30d, a CS Adaptation Function 30b, and a CAMEL Service Application 30c. Detailed capabilities and operations for the series of functions are described in 3GPP TS 23.206 V1.2.0.
Generally, the CS domain entities include a Visited Mobile Switching Center (VMSC) 24, a Gateway MSC (GMSC) 26, a gsmSCF, and the like. The IMS domain entities include a P-CSCF (Proxy Call Session Control Function), a S-CSCF(Serving Call Session Control Function) 20, a I-CSCF (Interrogating Call Session Control Function), a Media Gateway Control Function (MGCF) and a Home Subscriber Server (HSS) 40.
In order for the VCC UE to receive the VCC services, a registration procedure to the CS and IMS domains must previously be performed. In the related art VCC technology the CS registration and IMS registration which are associated with the VCC are as follows.
Specifically, a registration (or an attachment) to the CS domain is performed as the same as an existing registration to the CS domain. The registration to the IMS domain can be performed by the VCC UE only when an IP connectivity is available. The successive registration procedures are performed depending on a subscriber's iFC (initial Filter Criteria). The iFC refers to filter criteria which are a type of user information stored in the HSS. For a VCC subscriber, registration in a third party registration is defined to be performed to the VCC Application Server (VCC AS) 30 depending on the iFC.
FIG. 2 is a signal flowchart illustrating a procedure in which a VCC UE registers in an IMS domain according to the related art.
As illustrated in FIG. 2, a VCC UE 10 sends a REGISTER message to a S-CSCF 20 to initiate (start) a registration procedure (S1).
The S-CSCF 20 sends information related to a user of the VCC UE 10 to a HSS 40, thereby requesting subscriber information (represented as ‘Cx-Put/Cx-Pull’ in FIG. 2) (S2). The S-CSCF 20 receives the subscriber information from the HSS 40 (represented as ‘Cx-Put/Cx-Pull Resp’ in FIG. 2) (S3). The S-CSCF 20 then performs a service logic based upon the received subscriber information (e.g., using the iFC included in the subscriber information) to determine if the registration should be allowed (S4), and then selectively performs a third party registration procedure with the VCC AS 30 based on the determination result (S5). The VCC AS 30 delivers a 200 OK message to the VCC UE 10 via the S-CSCF 20 after the third party registration procedure is successfully performed (S6 and S7).
Once the VCC UE 10 completes the registration for the VCC service through steps S1 to S7, the network may adapt the following logic for calls associated with the VCC subscriber (i.e., the user of the VCC UE 10).
Call origination: when the corresponding VCC subscriber originates a call (i.e., when the call is an outgoing call), an anchoring in the IMS domain is performed for the VCC.
Call termination: when the network receives a call which the corresponding VCC subscriber terminates (i.e., when the call is an incoming call directed to the terminal), an anchoring in the IMS domain is performed for the VCC. A CS domain or IMS domain is selected (i.e., a domain selection is performed) and the call is terminated in the selected domain.
Domain selection: the corresponding VCC subscriber (i.e., the VCC UE user) selects the currently activated domain or the most suitable domain based upon operator policy.
Domain transfer: domain transfer for an ongoing call is initiated from a first domain to a second domain, e.g., from the CS domain to the IMS domain or vice versa.
As such, the VCC functions can be performed after the VCC UE 10 registers in the network (i.e., VCC AS 30). However, some times the VCC functions can not be supported or performed by the network due to particular conditions of the network, for example, network maintenance, traffic, a load of a specific external node, an internal problem of the VCC AS 30, or a temporary (or permanent) change of operator policies. In such cases, however, since there is no way or mechanism for the VCC UE 10 to know the fact that the VCC functions cannot be supported by the network according to the background art, the VCC UE 10 ends up performing or initiating unnecessarily or uselessly VCC related operations (e.g., domain selection for outgoing calls, or domain transfer therefor). This, from the perspective of the VCC UE 10, degrades the efficiency or capabilities of the VCC UE 10, e.g., it can result in a waste of resources, CPU power loss, battery consumption, radio access monitoring, or the like.